GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Entwicklungsstadium (Software)</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">Entwicklungsstadium (Software)</h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr">Ein Entwicklungsstadium ist in der <a href="Softwaretechnik" title="Softwaretechnik">Softwaretechnik</a> der Fertigstellungszustand, den ein zu erstellendes Softwareprodukt zu einem bestimmten Zeitpunkt erreicht hat oder erreichen soll. Die relevanten Stadien werden im Rahmen des <a href="Projektmanagement" title="Projektmanagement">Projektmanagements</a> zeitpunktbezogen und inhaltlich festgelegt. Sie basieren auf dem für das <a href="Projekt" title="Projekt">Projekt</a> gewählten <a href="Vorgehensmodell_zur_Softwareentwicklung" title="Vorgehensmodell zur Softwareentwicklung">Vorgehensmodell</a>, seinen Aktivitäten und <a href="Meilenstein_(Projektmanagement)" title="Meilenstein (Projektmanagement)">Meilensteinen</a> oder auf Festlegungen in herstellerspezifischen Methodenkonzepten und Entwicklungsumgebungen.

Im engeren Sinn bezieht sich der Begriff Entwicklungsstadium auf <a href="Ausf%C3%BChrbare_Datei" title="Ausführbare Datei">ausführbare</a> Software, d. h. auf lauffähige Programme, die im Rahmen von <a href="Releasemanagement" title="Releasemanagement">Releasemanagement</a>-Prozessen eines Projekts zum Testen oder an ihre Benutzer bereitgestellt werden. Je nach Projektsituation, oft in kleineren <a href="Softwarewartung" title="Softwarewartung">Wartungsprojekten</a>, entfallen manche Stadien, sie werden zusammengelegt oder die Software wird nur als eine einzige finale Version bereitgestellt.

In erweitertem Sinn ergeben sich unterschiedliche Entwicklungsstadien für Software im gesamten Projektverlauf, in dem auch in konzeptionellen Projektphasen Ergebnisse entstehen, die bestimmten Meilensteinen (‚Entwicklungsstadien‘) zugeordnet sind. Beispiel siehe.<a href="#cite_note-1">[1]</a> Am Ende jedes Stadiums werden die definierten Projektergebnisse in nachfolgende Bearbeitungsstufen übergeleitet.

Nach dem Erreichen des Software-Endzustands beginnt der Entwicklungszyklus i. d. R. mit Maßnahmen/Projekten zur Anwendungserweiterung wieder neu – mit dem Ziel einer neuen <a href="Version_(Software)" title="Version (Software)">Software-Version</a>.

<div class="mw-heading mw-heading2"><h2 id="Zweck/Unterschiede">Zweck/Unterschiede</h2></div>

Die Zielsetzung für die Festlegung mehrerer Entwicklungsstadien ist im Allgemeinen, im Projektverlauf Fixpunkte mit definierten Reifegraden zu erreichen, um die anschließenden Aktivitäten sicher(er) bearbeiten zu können. Häufig werden unterschiedliche Entwicklungsstadien z. B. beim <a href="Softwaretest" title="Softwaretest">Softwaretest</a> praktiziert, um in nachgelagerten <a href="Softwaretest#Teststufen" title="Softwaretest">Teststufen</a>/<a href="Softwaretest#Klassifikation_für_Testarten" title="Softwaretest">Testarten</a> Funktionsdetails überprüfen zu können, die auf bereits im vorhergehenden Stadium getesteten Funktionalitäten aufsetzen.

Unterschiede zwischen den einzelnen Software-Entwicklungsstadien für Computerprogramme können zum Beispiel folgende sein – um für den jeweils als Beispiel angegebenen Freigabezweck verwendet zu werden:

<ul><li>Manche Funktionen sind noch nicht realisiert; um einzelne Funktionen vorweg zu testen</li>

<li>… oder sind nur in einfacher Form (ohne Spezialfälle) realisiert; ebenfalls für erste/frühe Tests.</li>

<li>Die Software wurde im bisherigen Stadium nur durch bestimmte Testarten (wie Alphatests) überprüft; zur Durchführung von Betatests.</li>

<li>Die Software enthält noch Hilfsroutinen (z. B. <a href="Stub_(Programmierung)" title="Stub (Programmierung)">Stubs</a> oder Driver); zum Testen von Unterprogrammen.</li>

<li>Die Anwendung wird zur Übernahme in eine spezielle <a href="Systemumgebung" title="Systemumgebung">System- oder Testumgebung</a> bereitgestellt und ist ggf. zielsystemspezifisch adaptiert; zur Durchführung von Produktionstests oder Lasttests.</li>

<li>In der Anwendung sind Hilfsroutinen enthalten, die das Testen und die Dokumentation von Fehlerfällen unterstützen; für öffentliche Tester.</li>

<li>Stadiumbezogene Übergaben enthalten entweder die ganze Anwendung oder nur einzelne Komponenten zur (nachträglichen) Installation.</li>

<li>Die Anwendung ist vollständig einsatzbereit (letztes Stadium); zur finalen Übergabe in die <a href="Systemumgebung" title="Systemumgebung">Produktionsumgebung</a>.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Beispiele_für_Entwicklungsstadien">Beispiele für Entwicklungsstadien</h2></div>

Die Anzahl an Entwicklungsstadien mit ihren Soll-Reifegraden und auch ihre Bezeichnungen variieren erheblich. Insbesondere bei <a href="Standardsoftware" title="Standardsoftware">Standardsoftware</a> (inkl. <a href="Systemsoftware" title="Systemsoftware">Systemsoftware</a>) legen die Hersteller häufig fest, wie sie ihre Software stufenweise entwickeln, für wen und zu welchen Zwecken sie die jeweiligen Softwareversionen bereitstellen und wie sie diese Stufen benennen. Bei der Entwicklung von <a href="Individualsoftware" title="Individualsoftware">Individualsoftware</a> werden Entwicklungsstadien/Softwarereleases meist unternehmensindividuell praktiziert, sie sind oft nicht allgemeingültig festgelegt, sondern folgen projektspezifischen Gegebenheiten.

Entwicklungsstadien und Bezeichnungen für Softwarereleases können zum Beispiel sein:

<dl><dd>pre-Alpha → Alpha → Beta → Release Candidate → Release.</dd></dl>

In anderen Fällen praktiziert ein Hersteller Releasebezeichnungen wie die folgenden:

<dl><dd>CLOSED → FINAL STABLE → FINAL → CURRENT BUILD → SCHEDULED.<a href="#cite_note-2">[2]</a> </dd></dl>

Dabei ergeben sich zwischen solchen Haupt-Stadien in der Softwareentwicklung intern beliebig viele Software-Zwischenversionen, zum Beispiel aus mehreren Behebungsversuchen (und Teststufen) bei gemeldeten <a href="Programmfehler" title="Programmfehler">Programmfehlern</a>.

Für die Softwareentwicklung allgemein, d. h. nicht nur für ausführbare Programme geltend, sind beispielsweise folgende Stadien i. S. von Meilensteinen bekannt:

<dl><dd><a href="Projektdefinition" title="Projektdefinition">Projektdefinition</a>, <a href="Anforderungsanalyse_(Informatik)" title="Anforderungsanalyse (Informatik)">Anforderungsanalyse</a>, <a href="Lastenheft" title="Lastenheft">Lastenheft</a>, <a href="Pflichtenheft" title="Pflichtenheft">Pflichtenheft</a>, <a href="Statische_Codeanalyse" class="mw-redirect" title="Statische Codeanalyse">Codeanalyse</a>, Modultest, Systemtest, Projektabnahme</dd></dl>

<div class="mw-heading mw-heading2"><h2 id="Softwarestadien_für_ausführbare_Software">Softwarestadien für ausführbare Software </h2></div>

<div class="mw-heading mw-heading3"><h3 id="Pre-Alpha-Version"> Pre-Alpha-Version</h3></div>

Allgemein kann jeder beliebige Entwicklungszustand vor der ersten Alpha-Version als eine pre-Alpha-Version (von <a href="Latein" title="Latein">lateinisch</a> prae- ‚vorzeitig‘ und vom ersten Buchstaben des griechischen Alphabets <a href="Alpha" title="Alpha">Alpha</a>, auch als α' Schriftzeichen für 1) bezeichnet werden. Oft wird eine solche Version verwendet, wenn ein halbwegs fertiges Modul der Software vorgestellt werden soll. Eine weitere Bezeichnung ist die Entwicklervorschau (von <a href="Englische_Sprache" title="Englische Sprache">englisch</a> developer preview, abgekürzt auch oft DP).

<div class="mw-heading mw-heading3"><h3 id="Alpha-Version"> Alpha-Version</h3></div>

Die erste zum Test durch Fremde (also nicht die eigentlichen Entwickler) bestimmte Version eines <a href="Computerprogramm" title="Computerprogramm">Computerprogramms</a> wird oft Alpha-Version genannt. Obwohl der Begriff nicht exakt definiert ist, enthält in der Regel eine Alpha-Version bereits die grundlegenden Bestandteile des Softwareprodukts – es ist aber fast unerlässlich, dass in späteren Versionen der Funktionsumfang noch erweitert wird.

Insbesondere enthalten Alpha-Versionen zumeist <a href="Programmfehler" title="Programmfehler">Programmfehler</a> in Ausmaß oder Menge, die sie für den produktiven Einsatz ungeeignet machen.

Auch Alpha-Versionen können als Entwicklervorschauen, <a href="Englische_Sprache" title="Englische Sprache">englisch</a> Developer Previews oder Developer Releases, verfügbar gemacht werden. Dies geschieht meist in einem exklusiven Kreis für Entwickler von <a href="Drittanbieter" title="Drittanbieter">Drittanbietern</a>.

<div class="mw-heading mw-heading3"><h3 id="Beta-Version"> Beta-Version</h3></div>

Eine Beta-Version ist die erste Version eines <a href="Computerprogramm" title="Computerprogramm">Computerprogramms</a>, die vom Hersteller zu Testzwecken veröffentlicht wird. Der Begriff ist nicht exakt definiert, als Faustregel zur Abgrenzung einer Beta-Version von anderen Versionen gilt in der Regel, dass in ihr zwar alle wesentlichen Funktionen des Programms implementiert, aber noch nicht vollständig getestet sind. Das Programm kann oder wird daher unter Umständen noch viele, evtl. auch schwerwiegende Fehler enthalten, die einen produktiven Einsatz nicht empfehlenswert machen.

Der Nutzen eines <a href="Betatest" title="Betatest">Betatests</a> besteht insbesondere darin, dass Fehler, die typischerweise erst in der Praxis auftreten (wie zum Beispiel Konflikte mit anderen Programmen, Probleme mit bestimmten <a href="Hardware" title="Hardware">Hardwarekomponenten</a>, missverständlich umgesetzte <a href="Softwareanforderung" title="Softwareanforderung">Anforderungen</a> oder Unklarheiten in der <a href="Benutzerschnittstelle" title="Benutzerschnittstelle">Benutzeroberfläche</a>), schon vor der finalen Veröffentlichung (<a href="Englische_Sprache" title="Englische Sprache">englisch</a> Release) des Programms erkannt und behoben oder zumindest dokumentiert werden können. Als Betatester bezeichnet man im Allgemeinen den oder die ersten unabhängigen beziehungsweise anonymen Fremdtester und Anwender. Bei Betatestungen wird zwischen Open Beta (offene Beta) und Closed Beta (geschlossene Beta) unterschieden. Geschlossene Betaversionen werden einem begrenzten Personenkreis auf Einladung zum Benutzertest zur Verfügung gestellt, während bei einer Open Beta die zu testende Software für einen begrenzten Zeitraum einer breitere Masse an Internetnutzern zugänglich ist.<a href="#cite_note-3">[3]</a><a href="#cite_note-4">[4]</a><a href="#cite_note-5">[5]</a> Offene Betatestungen dienen mehreren Zwecken; einem Produkt oder einem Produktsystem einem umfangreicheren <a href="Stresstest" title="Stresstest">Stresstest</a> bzw. <a href="Lasttest_(Computer)" title="Lasttest (Computer)">Lasttest</a>, als dies bei einer Closed Beta möglich ist, zu unterziehen und damit einhergehend mögliche Kompatibilitätsprobleme zu identifizieren sowie das Produkt den potenziellen Kunden zu demonstrieren (<a href="Marketing" title="Marketing">Marketing</a>).

Beta-Versionen von Programmen sind in der Regel an der 0 als Hauptversionsnummer – diese Variante gilt natürlich nur für die Beta-Versionen vor der ersten fertigen Version (1.0) – oder dem Namenszusatz Beta zu erkennen.

Beta-Versionen werden normalerweise nicht auf dem gleichen Weg wie Release Candidates oder fertige Versionen vertrieben. Folgende Möglichkeiten finden Verwendung:

<ul><li>In (un)regelmäßigen Abständen werden definierte <a href="Schnappschuss_(Informationstechnik)" title="Schnappschuss (Informationstechnik)">Snapshots</a> (aktuelle Entwicklungszustände) aus dem <a href="Versionsverwaltung" title="Versionsverwaltung">Quellcodeverwaltungssystem</a> generiert und en bloc entweder im <a href="Quelltext" title="Quelltext">Quellcode</a> oder als vorkompiliertes Paket angeboten. Dies kann täglich (<a href="Nightly_Build" title="Nightly Build">Nightly Build</a>), wöchentlich oder zu beliebigen anderen Terminen, die die Entwickler für angemessen halten (z. B. nach Fertigstellung eines Subsystems), erfolgen. Eine solche Version kann auch ein automatisches <a href="Bugtracker" title="Bugtracker">Bugtracking</a>-Modul enthalten (siehe z. B. <a href="Amarok_(Software)" title="Amarok (Software)">Amarok</a>), um den Betatestern die <a href="Fehlerbericht" title="Fehlerbericht">Fehlerberichte</a> an die Entwickler zu erleichtern. Dies ist bei großen Projekten mit definierten Entwicklungszielen und einem festen Veröffentlichungszeitplan üblicherweise der Normalfall (z. B. bei <a href="Gnome" title="Gnome">GNOME</a>).</li>

<li>Die Betaversion wird im Quellcodeverwaltungssystem zu einer definierten Revision mit einem Tag (einer Markierung) versehen, aber sonst nicht gesondert behandelt. <a href="Linux-Distribution" title="Linux-Distribution">Unabhängige Anbieter</a> können dann diesen Entwicklungsstand als Basis für ihre vorkompilierten <a href="Paketverwaltung" title="Paketverwaltung">Pakete</a> verwenden. Dies kommt bei sich sehr schnell ändernden Projekten, die unter Umständen ganz ohne oder nur mit seltenen festen Releases arbeiten, bei denen aber trotzdem allgemeines Interesse an aktuellen Versionen besteht, zum Einsatz (z. B. <a href="Dirac_(Codec)" class="mw-redirect" title="Dirac (Codec)">Dirac</a>, <a href="Xine" title="Xine">Xine</a>).</li>

<li>Es gibt keine feste Beta-Version, Beta ist das aktuelle HEAD, also der sich ständig ändernde, tatsächliche Entwicklungsstand. Betatester müssen den derzeitigen Stand selbst aus dem Quellcodeverwaltungssystem herunterladen, konfigurieren und kompilieren, diese Tätigkeit wird normalerweise durch vom Projekt bereitgestellte Skripte automatisiert erledigt. Dies ist der häufigste Fall, kann aber auch mit einer der beiden vorherigen Methoden kombiniert werden (das ist die Regel).</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Perpetual_Beta">Perpetual Beta</h3></div>

Ein Begriff, der beschreibt, dass sich in Bezug auf die ständige Entwicklung des Internets auch Websites und Software kontinuierlich weiterentwickeln und somit nie wirklich fertig sind. Somit ist ein immerwährender Entwicklungszustand eingetreten, die „Perpetual Beta“. Entstanden als Schlagwort innerhalb des <a href="Web_2.0" title="Web 2.0">Web-2.0</a>-Konzeptes, das dem <a href="Extreme_Programming" title="Extreme Programming">Extreme-Programming</a>-Konzept der „<a href="Kontinuierliche_Integration" title="Kontinuierliche Integration">Continuous Integration</a>“ Rechnung trägt.

<div class="sieheauch" role="navigation" style="font-style:italic;">Siehe auch: <a href="Bananenprinzip" title="Bananenprinzip">Bananenprinzip</a></div>

<div class="mw-heading mw-heading3"><h3 id="Technical_Preview">Technical Preview</h3></div>

Wenn ein Produkt oder eine Komponente qualitätsgesichert freigegeben wird, die aber noch unvollständig ist, spricht man von einem Technical Preview.<a href="#cite_note-:0-6">[6]</a> Kunden können die Software testen, auch wenn sie noch dokumentierte Einschränkungen hat, z. B. noch nicht in allen finalen Sprachen <a href="Lokalisierung_(Softwareentwicklung)" title="Lokalisierung (Softwareentwicklung)">lokalisiert</a> ist.<a href="#cite_note-:0-6">[6]</a><a href="#cite_note-7">[7]</a>

<div class="mw-heading mw-heading3"><h3 id="Release_Candidate/Prerelease">Release Candidate/Prerelease</h3></div>

Ein Release Candidate (kurz RC, aus dem <a href="Englische_Sprache" title="Englische Sprache">Englischen</a> für Freigabekandidat), gelegentlich auch als Prerelease (aus dem Englischen etwa für „Vorabveröffentlichung“ oder „Vorabversion“) bezeichnet, ist eine abschließende Testversion einer Software. Darin sind alle Funktionen, die die endgültige Version der Software enthalten soll, schon verfügbar (sogenannter feature complete,) alle bis dahin bekannten Fehler sind behoben. Aus dem Release Candidate wird vor der Veröffentlichung die endgültige Version erstellt, um einen abschließenden Produkttest oder <a href="Systemtest" class="mw-redirect" title="Systemtest">Systemtest</a> durchzuführen. Dabei wird die Qualität der Software überprüft und nach verbliebenen <a href="Programmfehler" title="Programmfehler">Programmfehlern</a> gesucht.

Wird auch nur eine Kleinigkeit geändert, muss ein weiterer Release Candidate erstellt werden, und die Tests werden wiederholt. Die Release Candidates werden daher auch oft nummeriert (RC1, RC2 usw.). Erfolgen keine weiteren Änderungen und hält ein Release Candidate schließlich die geforderten Qualitätsstandards ein, so wird das Suffix RCx entfernt und damit die Version als Release (auch <a href="Englische_Sprache" title="Englische Sprache">englisch</a> final release, finale Veröffentlichung oder final version, finale Version) erklärt und veröffentlicht.

Versionen, die deutlich stabiler sind als Beta-Versionen, aber noch nicht den Teststand eines Release Candidate besitzen, werden in manchen Entwicklungsprojekten als Gamma-Version bezeichnet.

Bei <a href="Ger%C3%A4tetreiber" title="Gerätetreiber">Gerätetreibern</a> für <a href="Microsoft_Windows" title="Microsoft Windows">Windows</a> gibt es manchmal den Status <a href="Windows_Hardware_Quality_Labs" title="Windows Hardware Quality Labs">WHQL</a> Candidate (übersetzt WHQL-Kandidat). Hierbei handelt es sich um eine dem RC entsprechende Treiberversion, die der Hersteller zur WHQL-Prüfung eingereicht hat, die entsprechende Zertifizierung ist allerdings noch nicht erfolgt.

<div class="mw-heading mw-heading3"><h3 id="Release">Release</h3></div>

Die fertige und veröffentlichte Version einer Software wird als Release bezeichnet, manchmal auch als Hauptversion. Damit geht traditionell eine Erhöhung der <a href="Versionsnummer" title="Versionsnummer">Versionsnummer</a> einher. Bei einer mediengebundenen Verteilung wird diese Version zur Produktion an die Presswerke ausgeliefert, wo sie auf Datenträger wie <a href="CD-ROM" title="CD-ROM">CD-ROMs</a> oder <a href="DVD" title="DVD">DVDs</a> kopiert, also als tatsächlich greifbares Produkt hergestellt wird.

Für diesen Status haben sich außerdem verschiedene Bezeichnungen etabliert:

<dl><dt>Release to Manufacturing/Web (RTM/RTW), auch First Customer Shipment (FCS)</dt>

<dd>Bereit für die Vervielfältigung und Veröffentlichung im Netz (<a href="World_Wide_Web" title="World Wide Web">Web</a>)</dd>

<dt>Stable</dt>

<dd>für eine stabile Version, die nicht mehr verändert wird</dd>

<dt>Final</dt>

<dd>für die endgültige (finale) Version</dd>

<dt>General Availability (GA)</dt>

<dd>steht für eine allgemeine Verfügbarkeit. Der Begriff verdeutlicht, dass die Version für den Praxiseinsatz freigegeben ist und über verschiedene Medien verteilt wurde bzw. erhältlich ist.<a href="#cite_note-8">[8]</a><a href="#cite_note-9">[9]</a><a href="#cite_note-10">[10]</a></dd>

<dt>Gold, auch Golden Master (GM)</dt>

<dd>Mit dem Goldmaster wird die Version bezeichnet, welche schließlich ins Presswerk geht und (physisch) vervielfältigt wird. Um den Golden Master zu erreichen, müssen alle Fehler ausgebügelt und das Endprodukt vollständig komplett und auf das Endspeichermedium (die Goldmaster-DVD) gebrannt sein. Die Bezeichnung kommt aus der Musikindustrie. Die Goldmaster DVD wird ganz am Schluss hergestellt, kurz bevor sie ans Presswerk geschickt wird. Da es früher keine <a href="Softwareaktualisierung" title="Softwareaktualisierung">Updates</a> oder ähnliches gab, wurden mehrere Golden Master erstellt und ausgiebig getestet, bevor die Endversion ins Presswerk geschickt wurde. Mit dem Gold Master wird die endgültige Verkaufsversion bezeichnet, welche als Original ins Presswerk kommt und von der dann Kopien hergestellt werden. In der Musik- und Filmindustrie wird der Golden Master noch ausgiebig eingesetzt (CD und DVD-Produktion), in der Software-Industrie wurde er weitgehend durch Updates ersetzt. Von der Goldmaster-DVD gibt es normalerweise nur ein Stück.</dd></dl>

<div class="mw-heading mw-heading3"><h3 id="Benennungen">Benennungen</h3></div>

Die Bezeichnungen von Software-Versionen, Releases, sind grundsätzlich nicht genormt und lauten meist von Projekt zu Projekt unterschiedlich. Manche Hersteller legen in einer Art <a href="Roadmap" title="Roadmap">Roadmap</a> auch die beabsichtigten Bezeichnungen für (geplante) veröffentlichte Entwicklungsstände fest. Statt „Version“ oder „Release“ sind u. a. folgenden Benennungen für veröffentlichte Software gängig:

<dl><dt>Build</dt>

<dd>Das Ergebnis aus dem <a href="Compiler" title="Compiler">Kompilieren</a> des <a href="Quelltext" title="Quelltext">Quelltextes</a>. Dabei wird im <a href="Erstellungsprozess" title="Erstellungsprozess">Build-Prozess</a> meist die automatisch geführte <a href="Buildnummer" title="Buildnummer">Build-Nummer</a> um eins erhöht, vor allem, wenn der gesamte Quelltext kompiliert wird. Da die Software jedoch oft intern zum Testen kompiliert werden muss, trägt ein solcher Build meist dieselbe Versionsnummer wie der vorherige Build. Aber auch bei bereits veröffentlichten Versionen bzw. Releases werden oft zwecks Wartung, etwa wegen Funktionsupdates oder <a href="Patch_(Software)" title="Patch (Software)">Bugfixes</a>, neuere Builds als <a href="Softwareaktualisierung" title="Softwareaktualisierung">Update</a> veröffentlicht.</dd>

<dd>Manche Programme hängen bei der Version die Build-Nummer mit einem <a href="Bindestrich" class="mw-redirect" title="Bindestrich">Bindestrich</a> an, also z. B. 1.2.3-4567, wobei 1 die Hauptversionsnummer ist, 2.3 die Nebenversions- und Revisionsnummer und 4567 (nach dem Bindestrich) die Build-Nummer. Siehe auch <a href="Versionsnummer" title="Versionsnummer">Versionsnummer</a>.</dd>

<dt><a href="Version_(Software)" title="Version (Software)">Version</a></dt>

<dd>Ein Build, der eine eindeutige <a href="Versionsnummer" title="Versionsnummer">Versionsnummer</a> erhält, wird als eine neue Version eines Projekts geführt. Wird im Zuge von <a href="Hotfix" title="Hotfix">Hotfixes</a> oder Bugfixes z. B. eine Wartungsversion veröffentlicht, so kann diese die gleiche Versionsnummer tragen, aber eine höhere Build-Nummer oder einen namentlichen Zusatz, etwa „Service Release 1“ oder einfach „Maintenance Release.“</dd>

<dt>Release</dt>

<dd>Im Allgemeinen wird eine veröffentlichte Version als Release (deutsch: Veröffentlichung) bezeichnet. Interne Versionen, die nicht veröffentlicht werden, werden daher normalerweise nicht als Release bezeichnet, jedoch können solche Versionen oder Builds <a href="Leak" title="Leak">leaken</a> und somit ebenfalls an die Öffentlichkeit gelangen.</dd></dl>

Problematisch ist auch der Begriff Beta-Version, da er nicht eindeutig definiert ist und damit grundsätzlich für jeden unfertigen Entwicklungsstand stehen kann. So gibt es dieselben Benennung nach den Stadien der Entwicklung oft einerseits bezogen auf das gesamte Projekt, andererseits kann die Benennung auch lediglich auf erst kürzlich hinzugefügte Teilkomponenten bezogen sein (und der Rest der Projektes ist eigentlich stabil und daher keine Beta-Version).

Auch die veröffentlichte Software selbst hat meist unterschiedliche Namen. Neben der sogenannten “Release” gibt es auch die “Final” oder final version (zu Deutsch: fertige Version oder auch finale Version). Es gibt jedoch auch den Begriff “Stable”, also stabil, oft als stable version, stabile Version. Auch hier zeigt sich deutlich, dass verschiedene Benennungen durchaus üblich sind: statt einer Version kann auch eine Veröffentlichung namensgebend sein: eine final release eines Entwicklungsprojektes ist lediglich die veröffentlichte final version.

Bei unfertigen Versionen verhält es sich nicht anders. Ob nun <a href="#Pre-Alpha-Version">Pre-Alpha-</a>, <a href="#Alpha-Version">Alpha-</a> oder <a href="#Beta-Version">Beta-Version</a>: gebräuchlich ist “experimental” (experimentell), “unstable” (instabil), “testing” genauso wie “Preview”, jeweils optional wieder als “version” oder als “release”, aber auch als “build”. Ein <a href="Erstellungsprozess" title="Erstellungsprozess">Build</a> ist dabei am unspezifischsten, wird aber auch oft bei Veröffentlichungen verwendet, um den Status einer unfertigen Software zu verdeutlichen. Dennoch haben auch stabile und fertige Versionen oft eine Build-Nummer.

Eine Besonderheit ist die Benennung als <a href="Nightly_Build" title="Nightly Build">Nightly Build</a>, übersetzt: nächtlicher <a href="Erstellungsprozess" title="Erstellungsprozess">Build</a>. Ein Programm mit dieser Benennung kann zwischen vollkommen stabil bis gänzlich laufunfähig alles sein, weil der Prozess fast immer automatisiert in der Nacht abläuft (daher auch der Name) und dabei auf dem jeweiligen Stand des Quelltextes basiert, an dem die Entwickler tagsüber ihre Änderungen vornehmen. Der Quelltext könnte durch die letzten Änderungen defekt geworden sein (<a href="Englische_Sprache" title="Englische Sprache">englisch</a> broken), jedoch dennoch übersetzbar für den <a href="Compiler" title="Compiler">Compiler</a> bleiben, sodass zwar der Build-Prozess erfolgreich verläuft, das Programm jedoch dennoch nicht lauffähig ist. Daher sagt die Benennung als Nightly Build nichts über das Entwicklungsstadium des Softwareprojektes aus.

Üblich sind aber auch Benennungen, die unabhängig vom Entwicklungsstand eines Softwareprojekts an ein bestimmtes Publikum gerichtet sind. Diese verfolgen meist das für den Entwickler vorteilhafte Ziel, einen externen <a href="Betatest" title="Betatest">Betatest</a> unter bestimmten Bedingungen durchzuführen. Auch die Benennungen für weiterreichende „Beta-Programme“ sind nicht genormt und lauten von Projekt zu Projekt unterschiedlich, es gibt jedoch gemeinsame Schlagwörter:

<dl><dt>Internal Build oder Private Build</dt>

<dd>bezeichnet eine lauffähige Version eines Projekts, das nur intern getestet wird.</dd>

<dt>Developer Build</dt>

<dd>ist eine Testversion, die speziell für externe Entwickler (<a href="Englische_Sprache" title="Englische Sprache">englisch</a> developer) gedacht ist. Das kommt meist dann zur Anwendung, wenn viele <a href="Drittanbieter" title="Drittanbieter">Drittanbieter</a> für die Funktion des Projektes unerlässlich sind, z. B. bei einem <a href="Betriebssystem" title="Betriebssystem">Betriebssystem</a>, auf dem viele Programme von anderen Herstellern laufen können (bzw. kompatibel bleiben oder werden) sollen. Beispiel: <a href="Rhapsody_(Betriebssystem)" title="Rhapsody (Betriebssystem)">Rhapsody</a> Developer Release oder <a href="Mac_OS_X_Public_Beta" title="Mac OS X Public Beta">Mac OS X Developer Preview</a></dd>

<dt>Closed Beta</dt>

<dd>bezeichnet eine <a href="#Beta-Version">Beta-Version</a>, die einem exklusiven Kreis verfügbar gemacht wird. Beispiel: <a href="Microsoft_Windows_10" title="Microsoft Windows 10">Windows 10</a> als Insider Build oder Insider Preview, das für Teilnehmer eines offenen (da nur anmeldepflichtigen) Programms von Microsoft, das den Namen Insider Program trug, veröffentlicht wurde. Dabei war die Aufnahme von Testern zeitlich begrenzt.</dd>

<dt>Public Beta</dt>

<dd>bezeichnet eine <a href="#Beta-Version">Beta-Version</a>, die offen und uneingeschränkt für <a href="Early_Adopter" title="Early Adopter">Early-Adopter</a> gedacht ist. Beispiel: <a href="Mac_OS_X_Public_Beta" title="Mac OS X Public Beta">Mac OS X Public Beta</a>, eine Beta-Version von <a href="Mac_OS_X_10.0" title="Mac OS X 10.0">Mac OS X 10.0</a>.</dd>

<dt><a href="Early_Access" title="Early Access">Early Access</a></dt>

<dd>bezeichnet ein Kundenprogramm, das einen meist kostenpflichtigen Zugang (<a href="Englische_Sprache" title="Englische Sprache">englisch</a> access) zu frühen Test- und/oder Entwicklerversionen bietet. Dies ist vor allem bei <a href="Computerspiel" title="Computerspiel">Computerspielen</a> sehr beliebt, da es einerseits den Spielern bereits lange vor der Veröffentlichung eines Titels erlaubt, bestimmte Elemente der Spielewelt zu erforschen und bei Stabilitätstests auf verschiedener Hardware zu helfen, andererseits den Entwicklern ermöglicht, frühzeitig Änderungen vorzunehmen, die auf <a href="Feedbackmanagement" title="Feedbackmanagement">Feedback</a> der Spieler basieren. Early-Access-Programme sind zudem meist eine gute Finanzierungsquelle, da das <a href="Entwicklerstudio" title="Entwicklerstudio">Entwicklerstudio</a> bereits über Early-Access-Verkäufe Geld für die Entwicklung des Spiels vorab einnimmt.</dd></dl>

Eine weitere Art der Benennung stellt die Bezeichnung des Zwecks oder Grundes dar, für den eine bestimmte Version herausgegeben wird. Gebräuchlich sind hier vor allem die “Maintenance Release” und “Service Release”, also eine Veröffentlichung zum Zweck der Wartung. Übersetzt wird dies oft auch als Wartungsversion.

<div class="mw-heading mw-heading2"><h2 id="Fehlerbehebung_nach_Veröffentlichung">Fehlerbehebung nach Veröffentlichung</h2></div>

Um Fehler in bereits veröffentlichter Software zu beheben, geben Softwarehersteller sogenannte Aktualisierungen, <a href="Hotfix" title="Hotfix">Hotfixes</a>, <a href="Patch_(Software)" title="Patch (Software)">Patches</a> und <a href="Service_Pack" title="Service Pack">Service Packs</a> heraus. Bei vielen modernen Anwendungen und <a href="Betriebssystem" title="Betriebssystem">Betriebssystemen</a> können diese dann manuell oder automatisch über das <a href="Internet" title="Internet">Internet</a> bezogen werden.

<div class="mw-heading mw-heading2"><h2 id="Firefox_als_Beispiel">Firefox als Beispiel</h2></div>

Der Webbrowser <a href="Mozilla_Firefox" title="Mozilla Firefox">Mozilla Firefox</a> erscheint in sechswöchigen Abständen in vier verschiedenen Versionen: der experimentellen Version Firefox Nightly (pre-alpha), der experimentellen Version „Firefox Developer Edition“, der größtenteils stabilen Version Firefox Beta und der stabilen Version Firefox,<a href="#cite_note-11">[11]</a><a href="#cite_note-12">[12]</a> die sich jeweils in ihrer Versionsnummer unterscheiden, z. B. Firefox Aurora 11, Firefox Beta 10, Firefox 9. Außerdem kann man das „nächtliche“ <a href="Nightly_Build" title="Nightly Build">Nightly Build</a> (aktueller Entwicklungsstand, nur zum Testen geeignet) herunterladen. Auf diese Weise kann einerseits der Entwicklungsprozess beschleunigt werden, andererseits können Benutzer durch die Verwendung der Versionen Beta oder Aurora dazu beitragen, künftige Funktionen der stabilen Version zu testen, zu beurteilen und Programmfehler sowie Sicherheitslücken frühzeitig zu erkennen, da die Aurora-Version zwölf und die Beta-Version sechs Wochen vor dem endgültigen Erscheinen der stabilen Version der Öffentlichkeit zur Verfügung gestellt wird.

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Code-Freeze" title="Code-Freeze">Code-Freeze</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Manfred Precht, Nikolaus Meier, Dieter Tremel: EDV-Grundwissen. Pearson Education, München 2004, ISBN 3-8273-2129-8.</li>

<li>Mike Gunderloy: Coder to Developer. Wiley_Default, 2004, ISBN 0-7821-4327-X.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><a href="#cite_ref-1">↑</a> Ralf Ötinger Benutzergerechte Softwareentwicklung <a rel="nofollow" class="external autonumber" href="https://books.google.de/books?id=UkaoBgAAQBAJ&pg=PA250&lpg=PA250&dq=Entwicklung+Stadium+Software&source=bl&ots=PH8orM7fb2&sig=cPwRoObxzbSczGhnsZ4lvaJ-0Kk&hl=de&sa=X&ved=0ahUKEwjL7IOFpPrXAhXIsxQKHVm_B9sQ6AEIfDAI#v=onepage&q=Entwicklung%20Stadium%20Software&f=false">[1]</a> Stadien: Problemanalyse, Anforderungsdefinition

</li>

<li id="cite_note-2"><a href="#cite_ref-2">↑</a> es2000 Software für Sie gemacht <style data-mw-deduplicate="TemplateStyles:r261891140">

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20171211213529/https://www.es2000.de/de/dienstleistungen/support-lifecycle/">Archivierte Kopie</a> (<a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a> vom 11. Dezember 2017 im <a href="Internet_Archive" title="Internet Archive">Internet Archive</a>) Support Lifecycle

</li>

<li id="cite_note-3"><a href="#cite_ref-3">↑</a> <a rel="nofollow" class="external text" href="https://parallelhq.com/blog/what-does-closed-beta-mean">What Does Closed Beta Mean? Guide (2025).</a> In: parallelhq.com. Abgerufen am 23. Oktober 2025 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=What+Does+Closed+Beta+Mean%3F+Guide+%282025%29&rft.description=What+Does+Closed+Beta+Mean%3F+Guide+%282025%29&rft.identifier=https%3A%2F%2Fparallelhq.com%2Fblog%2Fwhat-does-closed-beta-mean&rft.language=en">

</li>

<li id="cite_note-4"><a href="#cite_ref-4">↑</a> <a rel="nofollow" class="external text" href="https://www.productplan.com/glossary/beta-test/">Beta Test.</a> In: ProductPlan. Abgerufen am 23. Oktober 2025 (amerikanisches Englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Beta+Test&rft.description=Beta+Test&rft.identifier=https%3A%2F%2Fwww.productplan.com%2Fglossary%2Fbeta-test%2F&rft.language=en-US">

</li>

<li id="cite_note-5"><a href="#cite_ref-5">↑</a> <a rel="nofollow" class="external text" href="https://launchdarkly.com/blog/beta-testing-programs/">Beta Testing Programs: Everything You Need to Know.</a> In: launchdarkly.com. Abgerufen am 23. Oktober 2025 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Beta+Testing+Programs%3A+Everything+You+Need+to+Know&rft.description=Beta+Testing+Programs%3A+Everything+You+Need+to+Know&rft.identifier=https%3A%2F%2Flaunchdarkly.com%2Fblog%2Fbeta-testing-programs%2F&rft.language=en">

</li>

<li id="cite_note-:0-6">↑ <a href="#cite_ref-:0_6-0">a</a> <a href="#cite_ref-:0_6-1">b</a> heise online: <a rel="nofollow" class="external text" href="https://www.heise.de/news/Technical-Preview-von-Windows-10-zum-Download-bereit-2410287.html">Technical Preview von Windows 10 zum Download bereit.</a> 1. Oktober 2014, abgerufen am 20. August 2024.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Technical+Preview+von+Windows+10+zum+Download+bereit&rft.description=Technical+Preview+von+Windows+10+zum+Download+bereit&rft.identifier=https%3A%2F%2Fwww.heise.de%2Fnews%2FTechnical-Preview-von-Windows-10-zum-Download-bereit-2410287.html&rft.creator=heise+online&rft.date=2014-10-01&rft.language=de">

</li>

<li id="cite_note-7"><a href="#cite_ref-7">↑</a> Philipp Moosdorf: <a rel="nofollow" class="external text" href="https://www.hardwareluxx.de/index.php/artikel/software/betriebssysteme/32848-windows-10-technical-preview-ausprobiert.html">Microsoft Windows 10 Technical Preview ausprobiert.</a> 3. Oktober 2014, abgerufen am 20. August 2024.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Microsoft+Windows+10+Technical+Preview+ausprobiert&rft.description=Microsoft+Windows+10+Technical+Preview+ausprobiert&rft.identifier=https%3A%2F%2Fwww.hardwareluxx.de%2Findex.php%2Fartikel%2Fsoftware%2Fbetriebssysteme%2F32848-windows-10-technical-preview-ausprobiert.html&rft.creator=Philipp+Moosdorf&rft.date=2014-10-03&rft.language=de">

</li>

<li id="cite_note-8"><a href="#cite_ref-8">↑</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20081225085004/http://www.microsoft.com/presspass/press/2008/nov08/11-12WESSPR.mspx">Microsoft Announces General Availability of Windows Small Business Server 2008 and Windows Essential Business Server 2008</a> (<a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a> vom 25. Dezember 2008 im <a href="Internet_Archive" title="Internet Archive">Internet Archive</a>)

</li>

<li id="cite_note-9"><a href="#cite_ref-9">↑</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20081205073547/http://www.vmware.com/company/news/releases/vmware_view_3.html">VMware Announces General Availability of VMware View 3, with Ground-Breaking Advances in Managing, Scaling and Personalizing Virtual Desktop Environments</a> (<a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a> vom 5. Dezember 2008 im <a href="Internet_Archive" title="Internet Archive">Internet Archive</a>)

</li>

<li id="cite_note-10"><a href="#cite_ref-10">↑</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20160711074922/http://www.cs.pomona.edu/classes/cs181f/supp/relphases.html">Release Phases & Criteria.</a> In: cs.pomona.edu. Archiviert vom <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fwww.cs.pomona.edu%2Fclasses%2Fcs181f%2Fsupp%2Frelphases.html">Original</a> am 11. Juli 2016; abgerufen am 24. Juli 2016 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Release+Phases+%26+Criteria&rft.description=Release+Phases+%26+Criteria&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20160711074922%2Fhttp%3A%2F%2Fwww.cs.pomona.edu%2Fclasses%2Fcs181f%2Fsupp%2Frelphases.html&rft.source=http://www.cs.pomona.edu/classes/cs181f/supp/relphases.html&rft.language=en">

</li>

<li id="cite_note-11"><a href="#cite_ref-11">↑</a> Johnathan Nightingale: <a rel="nofollow" class="external text" href="https://blog.mozilla.org/channels/2011/07/18/every-six-weeks/">Every Six Weeks.</a> In: blog.mozilla.org. 18. Juli 2011, abgerufen am 24. Juli 2016 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Every+Six+Weeks&rft.description=Every+Six+Weeks&rft.identifier=https%3A%2F%2Fblog.mozilla.org%2Fchannels%2F2011%2F07%2F18%2Fevery-six-weeks%2F&rft.creator=Johnathan+Nightingale&rft.date=2011-07-18&rft.language=en">

</li>

<li id="cite_note-12"><a href="#cite_ref-12">↑</a> Jens Ihlenfeld: <a rel="nofollow" class="external text" href="https://www.golem.de/1108/86003.html">Firefox weiter alle 6 Wochen, aber mit Versionsnummer.</a> <a href="Golem.de" class="mw-redirect" title="Golem.de">golem.de</a>, 26. August 2011, abgerufen am 24. Juli 2016.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AEntwicklungsstadium+%28Software%29&rft.title=Firefox+weiter+alle+6+Wochen%2C+aber+mit+Versionsnummer&rft.description=Firefox+weiter+alle+6+Wochen%2C+aber+mit+Versionsnummer&rft.identifier=https%3A%2F%2Fwww.golem.de%2F1108%2F86003.html&rft.creator=Jens+Ihlenfeld&rft.publisher=%5B%5Bgolem.de%5D%5D&rft.date=2011-08-26">

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-10-23" href="https://de.wikipedia.org/wiki/?title=Entwicklungsstadium_(Software)&oldid=260837069">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>